home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1996 June / EnigmA AMIGA RUN 08 (1996)(G.R. Edizioni)(IT)[!][issue 1996-06][EARSAN CD VII].iso / earcd / comm2 / xtick403.lha / FTSC / bwfwd.txt
Text File  |  1995-09-05  |  15KB  |  330 lines
  1.  Document:   fsc-00xx
  2.  Version:    draft 04
  3.  Date        Sept 5, 1995
  4.  Title:      File Forwarding in Fidonet Technology Networks
  5.  Author:     Robert Williamson FidoNet#1:167/104.0
  6.  
  7.  
  8.     Purpose: 
  9.         To  document  current practices in File Forwarding and the minimum
  10.     requirements and known extensions of the TIC file format.
  11.  
  12.     Acknowledgements:
  13.         The  TIC  file  format  was introduced by Barry Geller, in the MSDOS
  14.     File  Forwarder,  Tick.   Widely  used  extensions  to this format were
  15.     introduced by Harald Helms, in the MSDOS FileForwarder, AllFix.
  16.     
  17.     Terminology:
  18.     FTN - Fidonet Technology Network, such as FIDONET, AMIGANET or IBMNET.
  19.           Sometimes used interchangably with the term DOMAIN.
  20.  
  21.     FNC - FileName Conversion, process of converting filenames to msdos 8.3
  22.           format for transmission.
  23.  
  24.     FQFA - Fully Qualified FTN Address, the format is
  25.               FTN#Zone:Net/Node.Point
  26.  
  27.     CRC - Cyclic Redundancy Check, method to determine whether some data
  28.           has been altered. CRC-32 is used in File Forwarding.
  29.  
  30.     TIC - a file that contains control information for the File Forwarding
  31.         system.   These  files  are  named  xxSTAMP.TIC,  where  xx  is  an
  32.         abbreviation  representing  the  File  Forwarding  program name and
  33.         stamp  is  a  unixdate  stamp  truncated  to 6 characters.  
  34.  
  35.     UTC  -  Universal  Time  Coordinated,  the  time  at  the  0o  meridian
  36.         (Greenwich); previously called GMT.
  37.  
  38.  
  39.     ticking - the processing of reading and verifying a tic file and it's
  40.               associated file.
  41.  
  42.     forwarding  -  the  process  of  creating and sending tic files and the
  43.                    associated  file to one's downlinks.
  44.  
  45.     hatching - the process of introducing a new file into a fileecho
  46.  
  47.     cross-hatching - the process of forwarding a file from one fileecho
  48.                      (ususally restricted) to another
  49.  
  50.     Associated File - The file listed in the FILE field of the TIC file.
  51.  
  52.  
  53.         Note that use of UPPERCASE on tic file keywords in this document in
  54.         for display purposes only.
  55.  
  56.     Transmission of Files:
  57.  
  58.       The  associated  file,  that is, the file Listed in the FILE field of
  59.     the  TIC  file,  should  always be sent FIRST.  In the case of a failed
  60.     session, sending the FILE first prevents the orphaning of the file that
  61.     is normally caused by the deletion or movement of the TIC file to BAD.
  62.  
  63.       File  Forwarders  should  not  move or delete orphaned TIC files, but
  64.     this can neither be relied upon nor mandated.
  65.  
  66.       File  Forwarders  should  be  transparent to the renaming of files by
  67.     mailers.   This  means  that  if the mailer renames a duplicate file by
  68.     renaming  or bumpinmg a numeric extension, the File Forwarder should be
  69.     able  to  use  the  size and crc fields of the TIC to find and properly
  70.     rename the associated file referred to in the TIC.
  71.  
  72.       File Forwaders should always delete and dequeue unsent TIC files when
  73.     re-hatching  the  same  or  updated version of an associated file.  The
  74.     implementor  may  wish  to  allow  exceptions  for  periodicals such as
  75.     nodediffs and newsletters.
  76.  
  77.  
  78.     Format of a TIC file:
  79.  
  80.     Addressing:
  81.         In  a  tic  file  any form of FTN address representation from 3d to
  82.         FQFA  may  be  used.   All  File  Forwarders  must  understand  the
  83.         following formats:
  84.           zone:net/node                 - 3D - point 0 assumed
  85.           zone:net/node.point           - 4D
  86.           zone:net/node@ftn             - 5D - point 0 assumed
  87.           zone:net/node.point@ftn       - 5D 
  88.           ftn#zone:net/node.point       - fqfa
  89.  
  90.         File Forwarders should have configurable options per site as to the
  91.         type of addressing each of it's downlinks can understand.
  92.  
  93.     Dates:
  94.         All dates are expressed in UTC.
  95.  
  96.     TimeDateStamps:
  97.         All  TimeDateStamps are unix TimeDateStamps (# of seconds since Jan
  98.         1, 1970) in UTC and expressed in hexadecimal notation.
  99.  
  100.     Case Insensitivity:
  101.         the  format is completely case-insensitive.  It is general practice
  102.         that  the  first  letter  of a keyword is uppercase.  This is not a
  103.         requirement.
  104.  
  105.     Order Dependancy:
  106.         keywords are not order dependant.
  107.         Order  dependancy  is required in some groupings of a keyword, such
  108.         as PATH, VIA, DESC, LDESC and APP.
  109.  
  110.     Modification of address fields:
  111.         The  forwarding  site may modify the addresses in any keyword field
  112.         to  make  them  compliant  with  the addressing limitations of each
  113.         downlink.  
  114.  
  115.     Stripping of SeenBys:
  116.         The  forwarding site may strip seenbys to current FTN, ZONE or NET,
  117.         when not forwarding outside of current FTN, ZONE or NET.  This does
  118.         not  imply  nor  permit the stripping of a direct downlink which is
  119.         outside the range of the current strip filter.
  120.  
  121.  
  122.     Keywords:
  123.         There are no colons on keywords.
  124.   
  125.         Each keyword line is terminated with CR LF pair.
  126.  
  127.         The  maximum  length of a keyword line is 256 characters, including
  128.         the CRLF termination.  Some keyword lines may have a shorter limit.
  129.  
  130.         Keywords are separated from their data by a single space.  There is
  131.         no space if there is no data associated with the keyword.
  132.  
  133.         Keywords are case-insensitive and order independant.
  134.  
  135.         Keywords not understood are to be passed-though.
  136.  
  137.         Known Keywords that are blank should not be passed though.
  138.           For example, an empty AREADESC, could be either dropped or the
  139.           blank  replaced with the proper description.
  140.  
  141.         Most  Keywords  are  passed  through  when  processing.   There are
  142.         exceptions.   In  some  cases,  a  site-specific replacement may be
  143.         created.  Keywords marked with a ^ should not be passed-through.
  144.  
  145.         Keywords  marked  with a * are REQUIRED when processing a TIC file.
  146.         If  any  of these are missing, the tic file should be considered as
  147.         BAD and the associated file not forwarded to downlinks.
  148.  
  149.         Keywords marked with a # are CREATED when hatching or forwarding.
  150.  
  151.  
  152.     *#  AREA [AreaName]
  153.           the TagName of the file area.
  154.             eg.
  155.               AREA FTSC
  156.  
  157.         AREADESC [description of area]                    OPTIONAL
  158.           a  short  (80 chars) description of the file area.  This could be
  159.           the description found in FileBone.NA/NO
  160.             eg.
  161.               AREADESC SDS: FidoNet Technical Standards Committee
  162.           It  is  advisable  that the FDN identifier not be included if the
  163.           FDN line is in use.
  164.                     
  165.     *#  FILE [File being sent]
  166.           the name of the file being sent, no path
  167.           the filename must conform to msdos 8.3 format, unless it is known
  168.           that the receiving site can handle longer filenames.
  169.             eg:
  170.               FILE FSC-0nnn.L01
  171.      
  172.     ^#  FULLNAME [original filename before FNC]           OPTIONAL FNC only
  173.           the original filename (no path) before FileName Conversion    
  174.  
  175.     *#  CRC [CRC-32 in hex]
  176.           crc of the file being sent, 8 hexadecimal characters
  177.  
  178.     ^   MAGIC [MagicName]               OPTIONAL
  179.           Name  under  which the file can be FREQed from the site listed in
  180.           FROM.   This  is  NOT  passed  though when forwarding, unless the
  181.           MAGIC  name  is  the  same  on  the  forwarding  site.  It can be
  182.           replaced by the appropriate name.
  183.  
  184.         REPLACES [FileName]               OPTIONAL
  185.           Filename  (no  path)  of  a  file  hatched  in  the AREA that the
  186.           associated file replaces.  If the site expects FNC files, and the
  187.           filename  does  not conform to msdos 8.3 convention, the REPLACES
  188.           name should also be FNC.
  189.  
  190.         FDN [FDN name/description]        OPTIONAL
  191.           a  short (80 chars) description of the file distribution network.
  192.         This could be the description found in FileBone.NA/NO
  193.             eg:
  194.               FDN SDS - Software Distribution System
  195.  
  196.      #  ANNOUNCEDIN [EchoAreaName]
  197.           One or more space separated ecgho TAGNAMES in which HATCH of this
  198.           file  was  announced.   A File Forwader encountering this, should
  199.           check  the  list  against  those  tagnames in which it posts it's
  200.           file  reception  annoucements and not post in any tagname that is
  201.           present in both lists.
  202.           If  a tagname is in an FTN other than FIDONET, it should have the
  203.           FTN name appened.
  204.             eg:
  205.               ANNOUNCEDIN FILE_REQ NEWFILES@ibmnet AMY_NETDEV@AmigaNet
  206.  
  207.  
  208.      #  DESC [Description]
  209.           Description of the file, limited to 80 characters per line,
  210.           including CRLF termination.
  211.           If  multiple LDESC lines are used, the DESC line must provide the
  212.           maximum  information.   File  Forwarder's  are  not  required  to
  213.           passthough or make use of any extra DESC line after the first.
  214.             eg:
  215.               DESC File Forwarding in Fidonet Technology Networks
  216.  
  217.      #  LDESC [multiple lines]
  218.           A  long description of the file.  LDESC does NOT replace DESC, it
  219.           is  used  IN  ADDITION to the short description.  File Forwarders
  220.           are  not  required  make  use of LESC lines.  They must be passed
  221.           through, however.
  222.             eg:
  223.               LDESC Documents  current practices in File Forwarding and
  224.               LDESC the minimum requirements and known extensions of the
  225.               LDESC TIC file format.
  226.  
  227.      #  SIZE [Bytes]              OPTIONAL, SHOULD be required
  228.           Length of the file in bytes
  229.             eg:
  230.               SIZE 12512
  231.  
  232.         DATE [TimeDateStamp]
  233.           TimeDateStamp of the file. Can be date of creation of archive.
  234.  
  235.         RELEASE [TimeDateStamp]
  236.           Date  when file is TO BE released.  Usually used by SDS, but can
  237.           be used by ADS as well.
  238.  
  239.         AUTHOR [name]
  240.           Name  of  the author of the software package being hatched.  This
  241.           field  is  obviously not applicable to Newsletters, Nodelists and
  242.           Diffs and the like.
  243.  
  244.         SOURCE [authors_address]
  245.           FTN  address of the Author of the software package being hatched.
  246.           Not  necessary  the same as the ORIGIN hatch site.  Does not have
  247.           to be an FTN address.
  248.  
  249.      ^  APP [program] [Application Specific Information]
  250.           The  APP  keyword  is  a  keyword  known  to programs of the name
  251.           indicated.  APP'S are order dependent and must be passed though.
  252.   
  253.     *#  ORIGIN [Address]
  254.           Site where file entered the fileecho
  255.  
  256.     *^# FROM [Address] [Pwd]
  257.           Site  that  is  forwarding  the  file  to  the next site.  Pwd is
  258.           optional and rarely used, IF AT ALL.  Pwd is NEVER passed through.
  259.           The address must also appear in both PATH and SEENBY lines.
  260.  
  261.     ^   TO [Address]                        OPTIONAL
  262.           Site  to  which  this TIC and the associated file are being sent.
  263.           This keyword is included in the .TIC file when:
  264.             a)  the file is being routed via another system which permits
  265.                 such routing.  
  266.             b)  the  platform  in  use  does  not  have  any  FTN  software
  267.                 independant  method   of   associating   a  file  and  it's
  268.                 destination.   eg:   platforms  that  do not have filenotes
  269.                 that   could  contain  this  information  as  part  of  the
  270.                 filesystem.
  271.  
  272.           If  the address in the TO line is that of the receiving site, the
  273.           field  is  not  passed  through  when  forwarding  to  the  final
  274.           destination.  
  275.           If the address in the TO lines IS NOT that of the receiving site,
  276.           the  file  should  be  forwarded  to  the  TO  site, if a routing
  277.           agreement is in place with the sending site.
  278.  
  279.     *^# CREATED [by] [Program Banner]
  280.           File  Forwarder which created the TIC file.  This is generally in
  281.           the form:  
  282.               Created [by] program_name version [copyright_info]
  283.           The 'by' is optional but is generally used.
  284.  
  285.         VIA [FROM CREATED]                  OPTIONAL (tracking)
  286.           Copy  of  CREATED  line of FROM, with 'Created [by]' stripped and
  287.           FROM  prepended.   Always passed though.  The VIA is only created
  288.           by the receiving site when forwarding. It is never created by the
  289.           hatching  site.  Therefore, in any TIC file, the addresses in the
  290.           FROM and VIA should never be the same.
  291.             eg:
  292.               Via 1:167/100 ALLFIX+ 4.31 Copyright (C) 1992,95 Harald Harms (2:281/910)
  293.               Via FIDONET#1:167/104.0 XTick 4 Copyright (c) 1995 Robert Williamson FIDONET#1:167/104.0
  294.  
  295.     *#  PATH [Address] [TimeDateStamp] [date and time]
  296.           Address  of  Site  which  has forwarded the file.  TimeDateStamp,
  297.           date and time is that of when the Site received and Processed the
  298.           file. 
  299.           The address must also appear in SEENBY lines.
  300.   
  301.     * # SEENBY [Address]
  302.           Site  which  has  received the file.  There are multiple lines of
  303.           Seenby and they are unordered.
  304.  
  305.     *   PW [password]
  306.           Site or Area password.  This is case-insensitive and should be at
  307.           least 5 characters in length. 
  308.  
  309.         PGP [signature]
  310.           PrettyGoodPrivacy signature. To be discussed. 
  311.  
  312.     ^   ReceiptRequest -no data-               OPTIONAL
  313.           A  request  to the receiving system to generate a IsReturnReceipt
  314.           (attribute  word bit 13) messsage, in the same manner it would if
  315.           it  had  received  a  message  with  the FileAttached (bit 4) and
  316.           ReturnReceiptRequest  (bit  12)  attributes  and a subject of the
  317.           filename.  There is NO requirement to recognize this keyword.  It
  318.           may  be  passed  thought  at  the  option  of  the implementor or
  319.           operator.
  320.  
  321.         AuditRequest -no data-               OPTIONAL
  322.           A  request  to the receiving system to generate a IsReturnReceipt
  323.           (attribute  word bit 13) messsage, in the same manner it would if
  324.           it  had  received  a  message  with  the  FileAttach  (bit 4) and
  325.           AuditRequest  (bit  14) attributes and a subject of the filename.
  326.           There  is  NO  requirement  to recognize this keyword.  It should
  327.           ALWAYS be passed through.
  328.  
  329.  -eot-
  330.